Remarks 



Claim Rejections - 35 USC § 101 

The Applicant gratefully notes the Examiner's withdrawal of the previously issued 
rejection under 35 USC 101. 

Claim Rejections - 35 USC § 103 

Pending claims 1-9, 18, 20 and 22 stand rejected under 35 USC 103(a), as being 
unpatentable over Sciacca (US 6,760,761) in view of Thompson et al. (US 6,189,038). 
This rejection is traversed in light of the following remarks. 

The Applicant is grateful for the Examiner's Response to Arguments. However, the 
Applicant feels that the Examiner has not addressed the most fundamental point made 
in the arguments filed September 22, 2009. 

This fundamental point is that Sciacca teaches a standardized (that is, fixed ) interface to 
solve the problem of interoperability, whereas the presently claimed invention provides 
an adaptive software interface. By generating an adaptive interface, the present 
invention therefore represents a solution that is directly contrary to the approach taken 
in the prior art (that is, both Sciacca and Thompson). 

There is clear evidence for this conclusion. In Sciacca, col.1, lines 7-10, it is explicitly 
stated that the goal is to "standardize an interface" (see also col.11, lines 10-13). This is 
achieved by providing a device manager 110 (Figs. 1 and 3), which acts as an 
intermediary between the managed devices and the remote devices which wish to 
configure them. Instead of interacting directly with the interface of each individual 
managed device, the remote devices use the device manager 110, which presents a 
standardized interface (see col.1, lines 30-33). The device manager 110 
configures/manages each managed device, using that managed device's native 
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interface, on behalf of the remote devices. There is no generation of an adaptive 
interface: merely translation from one fixed native interface to another fixed 
standardized interface. 

There are perhaps two key misconceptions that have led the Examiner to reach the 
opposite conclusion: 

1. The Examiner believes that Sciacca discloses the collection of meta-data 
describing the semantics of interfaces for the client-end devices (as well as the remote 
devices), which is then stored in the configuration database. In the response to 
arguments, the Examiner cites col. 5, lines 41-52 of Sciacca as basis for this belief. 

In fact, this cited passage describes the input inspection engine 450 of the device 
configuration database 310. This engine "validates inputs from external entities". For 
example, it may perform checks to ensure that invalid data is not entered by an operator 
into the configuration database 420. Note that the data input into and stored in the 
configuration database is "configuration data corresponding to one or more managed 
devices" (col. 5, lines 3-4). Since the data pertains to the managed devices, it is clearly 
not meta-data describing the interface of the client-end (remote) device. Therefore (as 
explained in the previous response) Sciacca does not disclose generating, collating, or 
analyzing metadata describing the interface capabilities of the remote devices. 

2. The Examiner appears to confuse the adjustment of device configurations with 
the generation of an interface. At p. 3 of the present action, it is implied that Sciacca 
discloses generating an adaptive software interface because Sciacca "teaches the 
adjustment of device configurations so that they can comply with the needs of the 
infrastructure (in other words, so that they can communicate with the other network 
devices)". 

Firstly, it is incorrect to equate "complying with the needs of the infrastructure" with 
"communicating with other network devices". The device configurations are not adjusted 
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to ensure an ability to communicate with other devices - there is no basis for this 
interpretation. They are adjusted to meet a given management policy (col.6, lines 13- 
22). 



In any case, it is wrong to equate adjustment of a device's configuration (as in Sciacca) 
with the generation of an adaptive software interface which enables two entities to 
communicate (as in the present application). The configuration of a device (what it does; 
how it behaves) can change despite the software interface (the syntax and semantics of 
inputs or outputs - such as the command set) of the device remaining the same. This is 
true in Sciacca, where the configuration is adjusted by means of fixed interfaces . 
Sciacca contemplates the use of standard interfaces such as CORBA (col. 4, line 66 to 
col. 5, line 2 and col. 9, lines 61-63) for communication between the remote devices and 
the device manager, and between the device manager and the managed devices, 
respectively. In the alternative, Sciacca also notes that the interfaces to the managed 
devices can be proprietary. Neither possibility anticipates an adaptive (that is, 
changeable, variable) interface. 

Again, it is repeated that the whole purpose of the device manager of Sciacca is to 
avoid the need to adapt software interfaces, by providing an intermediary with a 
standardized interface to moderate between the fixed interfaces of various devices. 

As also explained in the previous response, Thompson does nothing to remedy the 
deficiencies of Sciacca, because it follows the same approach of mediating (translating) 
between various fixed interfaces, as opposed to generating an interface adaptively, as 
in the present invention. 

For all these reasons, the Applicant submits that the invention of claim 1 is patentable 
over Sciacca and Thompson, in isolation or in combination. 

Claim 20 recites similar technical features to claim 1. The Applicant submits that it is 
therefore patentable for the same reasons. 
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Claim 8 is directed to a method of determining a behavioral characteristic of a first entity 
in a relationship with at least one other entity. This requires the steps of "generating 
meta-data providing a structure containing at least one semantic information element 
describing a characteristic of an interface capability" for both the first entity and the at 
least one other entity . As discussed above, Sciacca discloses generating meta-data for 
at most one of two entities that wish to communicate. 

Since the step of generating meta-data for a second entity is not disclosed, Sciacca 
cannot disclose the remaining steps of claim 8 - namely, collating the semantic 
information elements of one entity with the other; and analyzing the collated pairs to 
determine a behavioral characteristic. 

As discussed above for claim 1, the approach of Sciacca is to provide a central 
intermediary with a single, standardized interface. This teaches away from the solution 
of generating, collating and analyzing metadata as claimed in claim 8. Sciacca has no 
need to determine behavioral characteristics, because these characteristics are fixed on 
both sides of the intermediary - on the one side by the single, standardized interface; 
and on the other side by the multiple device-specific command sets. Thompson 
confirms this approach. 

Claim 8 is therefore non-obvious in light of these references, for similar reasons to claim 
1. 

Likewise, claim 18 requires "generating at least one meta-data structure providing at 
least one semantic information element for each entity " (an initiator and a responder), 
followed by collating corresponding semantic information elements and analyzing them 
to determine the extent to which the initiator and the responder can generate a 
compatible interface. In accordance with this analysis, an interface is generated 
between said initiator and said responder which enables them to communicate across 
the network despite the fact that the interface capabilities of the entities are different. 
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As discussed above for claim 1, Sciacca discloses none of these steps. On the contrary, 
it teaches an approach that is fundamentally different - standardizing a fixed interface 
and providing an intermediary to map from the standard form to the device-specific 
form. Thompson takes the same approach. Claim 18 is therefore non-obvious, from 
Sciacca and Thompson, for similar reasons to claim 1 . 

The remaining dependent claims are submitted to be allowable at least by virtue of their 
dependence from an allowable independent claim. 

In view of the fact that all of the Examiner's comments have been addressed, further 
and favorable reconsideration is respectfully requested. 

January 20, 201 0 Respectfully submitted, 
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